Electronic communication among enterprises such as vendors and suppliers is currently accomplished through networks, including private networks and through public networks, such as the Internet. A participant in the network establishes a connection to the network, and is thus able to transmit a communication, such as an electronic message, to another participant in the data network. The data network delivers the communication from the source participant to the destination participant.
The primary alternative used today for connecting enterprises into a network is a combination of centralized and distributed architectures. A centralized architecture is characterized by a central node, or hub, through which all communications pass. A distributed architecture, on the other hand, provides multiple hubs through which electronic communication may be routed, instead of using a single, central hub. However, whether an architecture is centralized or distributed, the current methods for connecting enterprises suffer from the inability to maintain the overall state of the network.
Without the overall state being maintained, each company or centralized application would have to maintain state independently. A company, for example, would have to determine whether its connectivity to its supplier is operational before initiating any electronic communication with the supplier. For this to be accomplished, every company and application would have to connect directly with every other company and application. This connectivity approach is not feasible for industry segments with many companies and applications.
In addition, none of the existing system architectures provides a means to integrate process activities. With a centralized application, all processing occurs at the centralized application. A centralized system can conduct an overall or end-to-end business process, but needs to own the singular public processes as well. Thus, there is no inherent means to integrate process activities contained in other applications with the centralized applications. On the other hand, distributed systems allow several companies to conduct singular public processes. However, with distributed systems, not only is there a lack of any means to integrate process activities together, but greater complexity arises from the need to automate multiple company processes into an overall process.
Furthermore, establishing communication channels among participants in a business community can be costly and time-consuming. The primary alternative in use today is to tie together a set of public processes for one participant so that it can conduct business with other participants. This architecture can be described as a master—slave approach, where the central company serves as the hub and the other participants are spokes off of the hub.
This hub-and-spoke approach has many disadvantages. First, while there is reuse of singular public processes, there is no capability for reuse or sharing of compound processes. Each hub company owns the compound processes that are not exposed to any of the other hubs. Second, it is inherently difficult to orchestrate a business model that spans multiple companies, but which does not include the hub company in all the interactions. Third, in the case where an application service is needed that automates the interaction between two or more companies, but is not “owned” by any single company, there is no single place to integrate the application service. One is then forced to redundantly install the application service or portions of it in all places that require access. This results in slow implementation of the architecture, and a higher cost for implementing the system.